Sigstore en registros de imágenes: adopción y realidad

javi
Detalle de sello metálico oficial representando verificación criptográfica

En los últimos dos años, Sigstore ha pasado de proyecto experimental a estándar de facto para firma de artefactos OCI. Los grandes registros han añadido soporte nativo, proyectos upstream (Kubernetes, Jenkins, Node.js) firman sus releases, y WORK IN PROGRESS en herramientas de verificación. Este artículo cubre el estado real de adopción en registros en 2024, qué funciona en producción y qué sigue emergiendo.

El cambio del último año

Hitos concretos:

  • Kubernetes firma todas sus imágenes desde 1.24 (2022) con cosign.
  • Python Package Index (PyPI) implementa attestations con Sigstore (PEP 740, 2024).
  • NPM añadió provenance con Sigstore en Q4 2023.
  • Homebrew provenance en formulae.
  • Docker Hub beta de artifacts referenced (donde viven firmas Sigstore).

La dirección es clara: firma como esperado, no como excepción.

Adopción por registro

Docker Hub

Estado: soporte incipiente. Sigstore funciona vía OCI artifacts (cosign lo usa internamente), pero la UI de Docker Hub aún no muestra firmas prominentemente.

Usar Sigstore con Docker Hub:

cosign sign docker.io/myuser/myapp:1.0
cosign verify docker.io/myuser/myapp:1.0 --certificate-identity=... --certificate-oidc-issuer=...

Funciona, pero integración con Docker Scout y búsqueda de Docker Hub es limitada.

GitHub Container Registry (GHCR)

Estado: soporte pulido. GitHub Actions integra Sigstore nativamente via OIDC. Firmar una imagen en workflow es prácticamente una línea:

- uses: sigstore/cosign-installer@v3
- run: cosign sign --yes ghcr.io/owner/repo:${{ github.sha }}

El OIDC token del workflow vincula la firma a workflow + repo + actor. Verificable por cualquiera.

Adopción fuerte entre proyectos open source que publican en GHCR.

AWS Elastic Container Registry (ECR)

Estado: soporte vía OCI artifacts, pero sin integración ECR-native (aún). Hay plugins y scripts pero no es first-class.

AWS tiene su propio ECR image signing basado en AWS KMS, alternativo a Sigstore. Los dos coexisten. Algunas empresas usan Sigstore keyless, otras KMS signing nativo.

Google Artifact Registry (GAR)

Estado: integración con Binary Authorization (propio de GCP) y Sigstore. Buena experiencia en GCP-native workflows.

Google también tiene SLSA attestations integradas, que pueden ir firmadas con Sigstore.

Harbor

Estado: notario v2 / Sigstore nativamente soportado desde Harbor 2.5+.

Harbor es el registro open-source más avanzado en signing. Puede:

  • Almacenar firmas Sigstore.
  • Enforzar políticas de firma en proyectos específicos.
  • Integrar con Fulcio/Rekor públicos o privados.
  • Exponer estado de firma en UI.

Para organizaciones self-hosted, Harbor + Sigstore es setup mature.

Quay (Red Hat)

Estado: soporte maduro de Sigstore. Política de firma enforzable. Buena integración con OpenShift.

Flujos de verificación

Tres patrones en producción:

En admission controller

Kyverno con rule Sigstore:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-sigstore
spec:
  validationFailureAction: enforce
  rules:
    - name: check-signatures
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    identities:
                      - issuer: https://token.actions.githubusercontent.com
                        subject: https://github.com/myorg/*

Pods con imágenes no firmadas o firmadas por identidad incorrecta son rechazados.

En GitOps (Flux/Argo)

Flux 2 soporta verify Sigstore en sus Kustomization:

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: myapp
spec:
  imageRepositoryRef:
    name: myapp-repo
  policy:
    semver:
      range: ">=1.0.0"
  verify:
    provider: cosign
    secretRef:
      name: cosign-public-key

Si la firma no verifica, Flux no reconcilia.

En CI/CD pipeline

Verificar antes de deploy:

cosign verify $IMAGE \
  --certificate-identity-regexp='^https://github.com/myorg/.+$' \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
|| { echo "FIRMA INVALIDA"; exit 1; }

deploy-script $IMAGE

Provenance y SBOM firmados

Más allá de la imagen en sí, el ecosistema está firmando provenance y SBOM:

  • SLSA provenance: quién, cómo, cuándo construyó la imagen. Firmable con Sigstore.
  • SBOM: inventario de dependencias. Firmable.
  • Attestations: afirmaciones específicas (tests pasados, escaneo sin vulns).

Herramientas:

Challenges actuales

Ser honesto sobre lo que no funciona perfecto aún:

  • Rekor pública limits: Rekor pública tiene rate limits; empresas grandes necesitan propio.
  • Key distribution: verificar firma requiere conocer qué identidades aceptar. Governance necesario.
  • Rotación de identidades: si cambia el CI identity, verificación puede romper.
  • Registros legacy: algunos registros antiguos no soportan OCI artifacts.
  • Binary authorization vs Sigstore: algunos ecosistemas tienen mecanismos propios.

El debate: keyless vs KMS

Sigstore keyless se apoya en Fulcio público. Alternativas:

  • KMS signing: clave en AWS KMS, GCP KMS, HashiCorp Vault. No depende de Fulcio.
  • Static keypair: clave generada localmente, gestionada por la empresa.

Para empresas reguladas, KMS tiende a preferirse. Para la mayoría, keyless es más simple.

Casos reales

El horizonte: trusted supply chain

Más allá de firma de una imagen, la dirección es:

  • Build provenance completo (SLSA L3+).
  • Reproducible builds donde posible.
  • Policy as code sobre qué identidades y processes son aceptables.
  • Observabilidad del supply chain: visibilidad de qué llega a producción.

Sigstore es pieza fundacional. El edificio completo aún se construye.

Recomendaciones prácticas

Para una empresa adoptando hoy:

  1. Firmar con cosign keyless en CI si usas GitHub/GitLab/Gitea.
  2. Elegir un registry que soporte: GHCR para GitHub-native, Harbor para self-hosted.
  3. Verificación en admission con Kyverno o Gatekeeper.
  4. Documentar identidades aceptadas en Git (como policy).
  5. Alertar sobre imágenes sin firma en producción.
  6. Revisar rotación de identidades cada año.

Conclusión

Sigstore en registros de imágenes ha pasado de propuesta a realidad operable. GHCR, Harbor, Quay tienen soporte pulido; Docker Hub, ECR, GAR están en adopción. La política de “solo desplegar imágenes firmadas con identidad conocida” es factible hoy, no un futuro lejano. Para empresas serias sobre supply chain security, no implementarla en 2024 es una omisión deliberada. El tooling existe; la curva de aprendizaje es manejable; el ecosistema se mueve en esta dirección.

Síguenos en jacar.es para más sobre supply chain security, DevSecOps y registros OCI.

Entradas relacionadas